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Security Architecture for the Internet Protocol 


Status of this Memo 


This document specifies an Internet standards track protocol for the 
Internet community, and requests discussion and suggestions for 


improvements. Please refer to the current edition of the "Internet 
Official Protocol Standards" (STD 1) for the standardization state 
and status of this protocol. Distribution of this memo is unlimited. 


1. INTRODUCTION 


This memo describes the security mechanisms for IP version 4 (IPv4) 
and IP version 6 (IPv6) and the services that they provide. Each 


security mechanism is specified in a separate document. This 
document also describes key management requirements for systems 
implementing those security mechanisms. This document is not an 


overall Security Architecture for the Internet and is instead focused 
on IP-layer security. 


1.1 Technical Definitions 


This section provides a few basic definitions that are applicable to 
this document. Other documents provide more definitions and 
background information [VK83, HA94]. 


Authentication 
The property of knowing that the data received is the same as 
the data that was sent and that the claimed sender is in fact 
the actual sender. 


Integrity 
The property of ensuring that data is transmitted from source 
to destination without undetected alteration. 


Confidentiality 
The property of communicating such that the intended 
recipients know what was being sent but unintended 
parties cannot determine what was sent. 


Encryption 
A mechanism commonly used to provide confidentiality. 
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Non-repudiation 


SPI 


The property of a receiver being able to prove that the sender 
of some data did in fact send the data even though the sender 
might later desire to deny ever having sent that data. 


Acronym for "Security Parameters Index". An unstructured 
opaque index which is used in conjunction with the 
Destination Address to identify a particular Security 
Association. 


Security Association 


The set of security information relating to a given network 
connection or set of connections. This is described in 
detail below. 


Traffic Analysis 


The analysis of network traffic flow for the purpose of 
deducing information that is useful to an adversary. 
Examples of such information are frequency of transmission, 
the identities of the conversing parties, sizes of packets, 
Flow Identifiers used, etc. [Sch94]. 


1.2 Requirements Terminology 


In this document, the words that are used to define the significance 

of each particular requirement are usually capitalised. These words 

are: 

— MUST 
This word or the adjective "REQUIRED" means that the item is an 
absolute requirement of the specification. 

— SHOULD 
This word or the adjective "RECOMMENDED" means that there might 
exist valid reasons in particular circumstances to ignore this 
item, but the full implications should be understood and the case 
carefully weighed before taking a different course. 

— MAY 


This word or the adjective "OPTIONAL" means that this item is 
truly optional. One vendor might choose to include the item 
because a particular marketplace requires it or because it 
enhances the product, for example; another vendor may omit the 
same item. 
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1.3 Typical Use 


There are two specific headers that are used to provide security 
services in IPv4 and IPv6. These headers are the "IP Authentication 
Header (AH)" [Atk95a] and the "IP Encapsulating Security Payload 
(ESP)" [Atk95b] header. There are a number of ways in which these IP 
security mechanisms might be used. This section describes some of 
the more likely uses. These descriptions are not complete or 
exhaustive. Other uses can also be envisioned. 


The IP Authentication Header is designed to provide integrity and 
authentication without confidentiality to IP datagrams. The lack of 
confidentiality ensures that implementations of the Authentication 
Header will be widely available on the Internet, even in locations 
where the export, import, or use of encryption to provide 
confidentiality is regulated. The Authentication Header supports 
security between two or more hosts implementing AH, between two or 
more gateways implementing AH, and between a host or gateway 
implementing AH and a set of hosts or gateways. A security gateway 
is a system which acts as the communications gateway between external 
untrusted systems and trusted hosts on their own subnetwork. It also 
provides security services for the trusted hosts when they 
communicate with the external untrusted systems. A trusted 
subnetwork contains hosts and routers that trust each other not to 
engage in active or passive attacks and trust that the underlying 
communications channel (e.g., an Ethernet) isn’t being attacked. 


In the case where a security gateway is providing services on behalf 
of one or more hosts on a trusted subnet, the security gateway is 
responsible for establishing the security association on behalf of 
its trusted host and for providing security services between the 
security gateway and the external system(s). In this case, only the 
gateway need implement AH, while all of the systems behind the 
gateway on the trusted subnet may take advantage of AH services 
between the gateway and external systems. 


A security gateway which receives a datagram containing a recognised 
sensitivity label, for example IPSO [Ken91], from a trusted host 
should take that label’s value into consideration when 
creating/selecting an Security Association for use with AH between 
the gateway and the external destination. In such an environment, a 
gateway which receives a IP packet containing the IP Encapsulating 
Security Payload (ESP) should add appropriate authentication, 
including implicit (i.e., contained in the Security Association used) 
or explicit label information (e.g., IPSO), for the decrypted packet 
that it forwards to the trusted host that is the ultimate 
destination. The IP Authentication Header should always be used on 
packets containing explicit sensitivity labels to ensure end-to-end 
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label integrity. In environments using security gateways, those 
gateways MUST perform address-based IP packet filtering on 
unauthenticated packets purporting to be from a system known to be 
using IP security. 


The IP Encapsulating Security Payload (ESP) is designed to provide 
integrity, authentication, and confidentiality to IP datagrams 
[Atk95b]. The ESP supports security between two or more hosts 
implementing ESP, between two or more gateways implementing ESP, and 
between a host or gateway implementing ESP and a set of hosts and/or 
gateways. A security gateway is a system which acts as the 
communications gateway between external untrusted systems and trusted 
hosts on their own subnetwork and provides security services for the 
trusted hosts when they communicate with external untrusted systems. 
A trusted subnetwork contains hosts and routers that trust each other 
not to engage in active or passive attacks and trust that the 
underlying communications channel (e.g., an Ethernet) isn’t being 
attacked. Trusted systems always should be trustworthy, but in 
practice they often are not trustworthy. 


Gateway-to-gateway encryption is most valuable for building private 
virtual networks across an untrusted backbone such as the Internet. 
It does this by excluding outsiders. As such, it is often not a 
substitute for host-to-host encryption, and indeed the two can be and 
often should be used together. 


In the case where a security gateway is providing services on behalf 
of one or more hosts on a trusted subnet, the security gateway is 
responsible for establishing the security association on behalf of 
its trusted host and for providing security services between the 
security gateway and the external system(s). In this case, only the 
gateway need implement ESP, while all of the systems behind the 
gateway on the trusted subnet may take advantage of ESP services 
between the gateway and external systems. 


A gateway which receives a datagram containing a recognised 
sensitivity label from a trusted host should take that label’s value 
into consideration when creating/selecting a Security Association for 
use with ESP between the gateway and the external destination. In 
such an environment, a gateway which receives a IP packet containing 
the ESP should appropriately label the decrypted packet that it 
forwards to the trusted host that is the ultimate destination. The 
IP Authentication Header should always be used on packets containing 
explicit sensitivity labels to ensure end-to-end label integrity. 
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If there are no security gateways present in the connection, then two 
end systems that implement ESP may also use it to encrypt only the 
user data (e.g., TCP or UDP) being carried between the two systems. 
ESP is designed to provide maximum flexibility so that users may 
select and use only the security that they desire and need. 


Routing headers for which integrity has not been cryptographically 
protected SHOULD be ignored by the receiver. If this rule is not 
strictly adhered to, then the system will be vulnerable to various 
kinds of attacks, including source routing attacks [Bel89] [CB94] 
[CERT95]. 


While these documents do not specifically discuss IPv4 broadcast, 
these IP security mechanisms MAY be used with such packets. Key 
distribution and Security Association management are not trivial for 
broadcast applications. Also, if symmetric key algorithms are used 
the value of using cryptography with a broadcast packet is limited 
because the receiver can only know that the received packet came from 
one of many systems knowing the correct key to use. 


1.4 Security Associations 


The concept of a "Security Association" is fundamental to both the IP 
Encapsulating Security Payload and the IP Authentication Header. The 
combination of a given Security Parameter Index (SPI) and Destination 
Address uniquely identifies a particular "Security Association". An 
implementation of the Authentication Header or the Encapsulating 
Security Payload MUST support this concept of a Security Association. 
An implementation MAY also support other parameters as part of a 
Security Association. A Security Association normally includes the 
parameters listed below, but might include additional parameters as 
well: 


- Authentication algorithm and algorithm mode being used with 
the IP Authentication Header [REQUIRED for AH implementations]. 


- Key(s) used with the authentication algorithm in use with 
the Authentication Header [REQUIRED for AH implementations]. 


- Encryption algorithm, algorithm mode, and transform being 
used with the IP Encapsulating Security Payload [REQUIRED for 


ESP implementations]. 


- Key(s) used with the encryption algorithm in use with the 
Encapsulating Security Payload [REQUIRED for ESP implementations]. 
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- Presence/absence and size of a cryptographic synchronisation or 
initialisation vector field for the encryption algorithm [REQUIRED 
for ESP implementations]. 


- Authentication algorithm and mode used with the ESP transform 
(if any is in use) [RECOMMENDED for ESP implementations]. 


- Authentication key(s) used with the authentication algorithm 
that is part of the ESP transform (if any) [RECOMMENDED for 
ESP implementations]. 


- Lifetime of the key or time when key change should occur 
[RECOMMENDED for all implementations]. 


- Lifetime of this Security Association [RECOMMENDED for all 
implementations]. 


- Source Address(es) of the Security Association, might be a 
wildcard address if more than one sending system shares the 
same Security Association with the destination [RECOMMENDED 
for all implementations]. 


- Sensitivity level (for example, Secret or Unclassified) 
of the protected data [REQUIRED for all systems claiming 
to provide multi-level security, RECOMMENDED for all other systems]. 


The sending host uses the sending userid and Destination Address to 
select an appropriate Security Association (and hence SPI value). 

The receiving host uses the combination of SPI value and Destination 
Address to distinguish the correct association. Hence, an AH 
implementation will always be able to use the SPI in combination with 
the Destination Address to determine the security association and 
related security configuration data for all valid incoming packets. 
When a formerly valid Security Association becomes invalid, the 
destination system(s) SHOULD NOT immediately reuse that SPI value and 
instead SHOULD let that SPI value become stale before reusing it for 
some other Security Association. 


A security association is normally one-way. An authenticated 
communications session between two hosts will normally have two 
Security Parameter Indexes in use (one in each direction). The 
combination of a particular Security Parameter Index and a particular 
Destination Address uniquely identifies the Security Association. 

The Destination Address may be a unicast address or a multicast group 
address. 
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The receiver-orientation of the Security Association implies that, in 
the case of unicast traffic, the destination system will normally 
select the SPI value. By having the destination select the SPI 
value, there is no potential for manually configured Security 
Associations that conflict with automatically configured (e.g., via a 
key management protocol) Security Associations. For multicast 
traffic, there are multiple destination systems but a single 
destination multicast group, so some system or person will need to 
select SPIs on behalf of that multicast group and then communicate 
the information to all of the legitimate members of that multicast 
group via mechanisms not defined here. 


Multiple senders to a multicast group MAY use a single Security 
Association (and hence Security Parameter Index) for all traffic to 
that group. In that case, the receiver only knows that the message 
came from a system knowing the security association data for that 
multicast group. A receiver cannot generally authenticate which 
system sent the multicast traffic when symmetric algorithms (e.g., 
DES, IDEA) are in use. Multicast traffic MAY also use a separate 
Security Association (and hence SPI) for each sender to the multicast 
group . If each sender has its own Security Association and 
asymmetric algorithms are used, then data origin authentication is 
also a provided service. 


2. DESIGN OBJECTIVES 


This section describes some of the design objectives of this security 
architecture and its component mechanisms. The primary objective of 
this work is to ensure that IPv4 and IPv6 will have solid 
cryptographic security mechanisms available to users who desire 
security. 


These mechanisms are designed to avoid adverse impacts on Internet 
users who do not employ these security mechanisms for their traffic. 
These mechanisms are intended to be algorithm-independent so that the 
cryptographic algorithms can be altered without affecting the other 
parts of the implementation. These security mechanisms should be 
useful in enforcing a variety of security policies. 


Standard default algorithms (keyed MD5, DES CBC) are specified to 
ensure interoperability in the global Internet. The selected default 
algorithms are the same as the standard default algorithms used in 
SNMPv2 [GM93]. 
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3. IP-LAYER SECURITY MECHANISMS 


There are two cryptographic security mechanisms for IP. The first is 
the Authentication Header which provides integrity and authentication 
without confidentiality [Atk95a]. The second is the Encapsulating 
Security Payload which always provides confidentiality, and 
(depending on algorithm and mode) might also provide integrity and 
authentication [Atk95b]. The two IP security mechanisms may be used 
together or separately. 


These IP-layer mechanisms do not provide security against a number of 
traffic analysis attacks. However, there are several techniques 
outside the scope of this specification (e.g., bulk link encryption) 
that might be used to provide protection against traffic analysis 
[VK83]. 


3.1 AUTHENTICATION HEADER 


The IP Authentication Header holds authentication information for its 
IP datagram [Atk95a]. It does this by computing a cryptographic 
authentication function over the IP datagram and using a secret 
authentication key in the computation. The sender computes the 
authentication data prior to sending the authenticated IP packet. 
Fragmentation occurs after the Authentication Header processing for 
outbound packets and prior to Authentication Header processing for 
inbound packets. The receiver verifies the correctness of the 
authentication data upon reception. Certain fields which must change 
in transit, such as the "TTL" (IPv4) or "Hop Limit" (IPv6) field, 
which is decremented on each hop, are omitted from the authentication 
calculation. However the omission of the Hop Limit field does not 
adversely impact the security provided. Non-repudiation might be 
provided by some authentication algorithms (e.g., asymmetric 
algorithms when both sender and receiver keys are used in the 
authentication calculation) used with the Authentication Header, but 
it is not necessarily provided by all authentication algorithms that 
might be used with the Authentication Header. The default 
authentication algorithm is keyed MD5, which, like all symmetric 
algorithms, cannot provide non-repudiation by itself. 

Confidentiality and traffic analysis protection are not provided by 
the Authentication Header. 


Use of the Authentication Header will increase the IP protocol 
processing costs in participating systems and will also increase the 
communications latency. The increased latency is primarily due to 
the calculation of the authentication data by the sender and the 
calculation and comparison of the authentication data by each 
receiver for each IP datagram containing an Authentication Header 
(AH). 
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The Authentication Header provides much stronger security than exists 
in most of the current Internet and should not affect exportability 
or significantly increase implementation cost. While the 
Authentication Header might be implemented by a security gateway on 
behalf of hosts on a trusted network behind that security gateway, 


this mode of operation is not encouraged. Instead, the 
Authentication Header should be used from origin to final 
destination. 


All IPv6-capable hosts MUST implement the IP Authentication Header 
with at least the MD5 algorithm using a 128-bit key. IPv4-systems 
claiming to implement the Authentication Header MUST implement the IP 
Authentication Header with at least the MD5 algorithm using a 128-bit 
key [MS95]. An implementation MAY support other authentication 
algorithms in addition to keyed MD5. 


3.2 ENCAPSULATING SECURITY PAYLOAD 


The IP Encapsulating Security Payload (ESP) is designed to provide 
integrity, authentication, and confidentiality to IP datagrams 
[Atk95b]. It does this by encapsulating either an entire IP datagram 
or only the upper-layer protocol (e.g., TCP, UDP, ICMP) data inside 
the ESP, encrypting most of the ESP contents, and then appending a 
new cleartext IP header to the now encrypted Encapsulating Security 
Payload. This cleartext IP header is used to carry the protected 
data through the internetwork. 


3.2.1 Description of the ESP Modes 


There are two modes within ESP. The first mode, which is known as 
Tunnel-mode, encapsulates an entire IP datagram within the ESP 
header. The second mode, which is known as Transport-—mode, 
encapsulates an upper-layer protocol (for example UDP or TCP) inside 
ESP and then prepends a cleartext IP header. 


3.2.2 Usage of ESP 


ESP works between hosts, between a host and a security gateway, or 
between security gateways. This support for security gateways permits 
trustworthy networks behind a security gateway to omit encryption and 
thereby avoid the performance and monetary costs of encryption, while 
still providing confidentiality for traffic transiting untrustworthy 
network segments. When both hosts directly implement ESP and there 
is no intervening security gateway, then they may use the Transport- 
mode (where only the upper layer protocol data (e.g., TCP or UDP) is 
encrypted and there is no encrypted IP header). This mode reduces 
both the bandwidth consumed and the protocol processing costs for 
users that don’t need to keep the entire IP datagram confidential. 
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ESP works with both unicast and multicast traffic. 
3.2.3 Performance Impacts of ESP 


The encapsulating security approach used by ESP can noticeably impact 
network performance in participating systems, but use of ESP should 
not adversely impact routers or other intermediate systems that are 
not participating in the particular ESP association. Protocol 
processing in participating systems will be more complex when 
encapsulating security is used, requiring both more time and more 
processing power. Use of encryption will also increase the 
communications latency. The increased latency is primarily due to 
the encryption and decryption required for each IP datagram 
containing an Encapsulating Security Payload. The precise cost of 
ESP will vary with the specifics of the implementation, including the 
encryption algorithm, key size, and other factors. Hardware 
implementations of the encryption algorithm are recommended when high 
throughput is desired. 


For interoperability throughout the worldwide Internet, all 
conforming implementations of the IP Encapsulating Security Payload 
MUST support the use of the Data Encryption Standard (DES) in 
Cipher-Block Chaining (CBC) Mode as detailed in the ESP 
specification. Other confidentiality algorithms and modes may also 
be implemented in addition to this mandatory algorithm and mode. 
Export and use of encryption are regulated in some countries [OTA94]. 


3.3 COMBINING SECURITY MECHANISMS 


In some cases the IP Authentication Header might be combined with the 
IP Encapsulating Security Protocol to obtain the desired security 
properties. The Authentication Header always provides integrity and 
authentication and can provide non-repudiation if used with certain 
authentication algorithms (e.g., RSA). The Encapsulating Security 
Payload always provides integrity and confidentiality and can also 
provide authentication if used with certain authenticating encryption 
algorithms. Adding the Authentication Header to a IP datagram prior 
to encapsulating that datagram using the Encapsulating Security 
Protocol might be desirable for users wishing to have strong 
integrity, authentication, confidentiality, and perhaps also for 
users who require strong non-repudiation. When the two mechanisms 
are combined, the placement of the IP Authentication Header makes 
clear which part of the data is being authenticated. Details on 
combining the two mechanisms are provided in the IP Encapsulating 
Security Payload specification [At94b]. 
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3.4 OTHER SECURITY MECHANISMS 


Protection from traffic analysis is not provided by any of the 
security mechanisms described above. It is unclear whether 
meaningful protection from traffic analysis can be provided 
economically at the Internet Layer and it appears that few Internet 
users are concerned about traffic analysis. One traditional method 
for protection against traffic analysis is the use of bulk link 
encryption. Another technique is to send false traffic in order to 
increase the noise in the data provided by traffic analysis. 
Reference [VK83] discusses traffic analysis issues in more detail. 


4. KEY MANAGEMENT 


The Key Management protocol that will be used with IP layer security 
is not specified in this document. However, because the key 
management protocol is coupled to AH and ESP only via the Security 
Parameters Index (SPI), we can meaningfully define AH and ESP without 
having to fully specify how key management is performed. We envision 
that several key management systems will be usable with these 
specifications, including manual key configuration. Work is ongoing 
within the IETF to specify an Internet Standard key management 
protocol. 


Support for key management methods where the key management data is 
carried within the IP layer is not a design objective for these IP- 
layer security mechanisms. Instead these IP-layer security 
mechanisms will primarily use key management methods where the key 
management data will be carried by an upper layer protocol, such as 
UDP or TCP, on some specific port number or where the key management 
data will be distributed manually. 


This design permits clear decoupling of the key management mechanism 
from the other security mechanisms, and thereby permits one to 
substitute new and improved key management methods without having to 
modify the implementations of the other security mechanisms. This 
separation of mechanism is clearly wise given the long history of 
subtle flaws in published key management protocols [NS78, NS81]. 
What follows in this section is a brief discussion of a few 
alternative approaches to key management. Mutually consenting 
systems may additionally use other key management approaches by 
private prior agreement. 


4.1 Manual Key Distribution 
The simplest form of key management is manual key management, where a 


person manually configures each system with its own key and also with 
the keys of other communicating systems. This is quite practical in 
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small, static environments but does not scale. It is not a viable 
medium-term or long-term approach, but might be appropriate and 
useful in many environments in the near-term. For example, within a 


small LAN it is entirely practical to manually configure keys for 
each system. Within a single administrative domain it is practical 
to configure keys for each router so that the routing data can be 
protected and to reduce the risk of an intruder breaking into a 
router. Another case is where an organisation has an encrypting 
firewall between the internal network and the Internet at each of its 
sites and it connects two or more sites via the Internet. In this 
case, the encrypting firewall might selectively encrypt traffic for 
other sites within the organisation using a manually configured key, 
while not encrypting traffic for other destinations. It also might 
be appropriate when only selected communications need to be secured. 


4.2 Some Existing Key Management Techniques 


There are a number of key management algorithms that have been 
described in the public literature. Needham & Schroeder have 
proposed a key management algorithm which relies on a centralised key 
distribution system [NS78, NS81]. This algorithm is used in the 
Kerberos Authentication System developed at MIT under Project Athena 
[KB93]. Diffie and Hellman have devised an algorithm which does not 
require a centralised key distribution system [DH76]. Unfortunately, 
the original Diffie-Hellman technique is vulnerable to an active "man 
in the middle" attack [Sch93, p. 43-44]. However, this vulnerability 
can be mitigated by using signed keys to authentically bootstrap into 
the Diffie-Hellman exchange [Sch93, p. 45]. 


4.3 Automated Key Distribution 


Widespread deployment and use of IP security will require an 
Internet-standard scalable key management protocol. Ideally such a 
protocol would support a number of protocols in the Internet protocol 
suite, not just IP security. There is work underway within the IETF 
to add signed host keys to the Domain Name System [EK94] The DNS keys 
enable the originating party to authenticate key management messages 
with the other key management party using an asymmetric algorithm. 
The two parties would then have an authenticatible communications 
channel that could be used to create a shared session key using 
Diffie-Hellman or other means [DH76] [Sch93]. 


4.4 Keying Approaches for IP 


There are two keying approaches for IP. The first approach, called 
host-oriented keying, has all users on host 1 share the same key for 
use on traffic destined for all users on host 2. The second 
approach, called user-oriented keying, lets user A on host 1 have one 
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or more unique session keys for its traffic destined for host 2; such 


session keys are not shared with other users on hosti. For example, 
user A’s ftp session might use a different key than user A’s telnet 
session. In systems claiming to provide multi-level security, user A 


will typically have at least one key per sensitivity level in use 
(e.g., one key for UNCLASSIFIED traffic, a second key for SECRET 
traffic, and a third key for TOP SECRET traffic). Similarly, with 
user-oriented keying one might use separate keys for information sent 
to a multicast group and control messages sent to the same multicast 
group. 


In many cases, a single computer system will have at least two 
mutually suspicious users A and B that do not trust each other. When 
host-oriented keying is used and mutually suspicious users exist, it 
is sometimes possible for user A to determine the host-oriented key 
via well known methods, such as a Chosen Plaintext attack. Once user 
A has improperly obtained the key in use, user A can then either read 
user B’s encrypted traffic or forge traffic from user B. When user- 
oriented keying is used, certain kinds of attack from one user onto 
another user’s traffic are not possible. 


IP Security is intended to be able to provide Authentication, 
Integrity, and Confidentiality for applications operating on 
connected end systems when appropriate algorithms are in use. 
Integrity and Confidentiality can be provided by host-oriented keying 
when appropriate dynamic key management techniques and appropriate 
algorithms are in use. However, authentication of principals using 
applications on end-systems requires that processes running 
applications be able to request and use their own Security 
Associations. In this manner, applications can make use of key 
distribution facilities that provide authentication. 


Hence, support for user-oriented keying SHOULD be present in all IP 
implementations, as is described in the "IP Key Management 
Requirements" section below. 


4.5 Multicast Key Distribution 


Multicast key distribution is an active research area in the 
published literature as of this writing. For multicast groups having 
relatively few members, manual key distribution or multiple use of 
existing unicast key distribution algorithms such as modified 
Diffie-Hellman appears feasible. For very large groups, new scalable 
techniques will be needed. The use of Core-Based Trees (CBT) to 
provide session key management as well as multicast routing might be 
an approach used in the future [BFC93]. 
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4.6 IP Key Management Requirements 


This section defines key management requirements for all IPv6 
implementations and for those IPv4 implementations that implement the 
IP Authentication Header, the IP Encapsulating Security Payload, or 
both. It applies equally to the IP Authentication Header and the IP 
Encapsulating Security Payload. 


All such implementations MUST support manual configuration of 
Security Associations. 


All such implementations SHOULD support an Internet standard Security 
Association establishment protocol (e.g., IKMP, Photuris) once such a 
protocol is published as an Internet standards-track RFC. 


Implementations MAY also support other methods of configuring 
Security Associations. 


Given two endpoints, it MUST be possible to have more than one 
concurrent Security Association for communications between them. 
Implementations on multi-user hosts SHOULD support user granularity 
(i.e., “user-oriented") Security Associations. 


All such implementations MUST permit the configuration of host- 
oriented keying. 


A device that encrypts or authenticates IP packets originated other 
systems, for example a dedicated IP encryptor or an encrypting 
gateway, cannot generally provide user-oriented keying for traffic 
originating on other systems. Such systems MAY additionally 
implement support for user-oriented keying for traffic originating on 
other systems. 


The method by which keys are configured on a particular system is 
implementation-defined. A flat file containing security association 
identifiers and the security parameters, including the key(s), is an 
example of one possible method for manual key distribution. An IP 
system MUST take reasonable steps to protect the keys and other 
security association information from unauthorised examination or 
modification because all of the security lies in the keys. 


5. USAGE 
This section describes the possible use of the security mechanisms 
provided by IP in several different environments and applications in 


order to give the implementer and user a better idea of how these 
mechanisms can be used to reduce security risks. 
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5.1 USE WITH FIREWALLS 


Firewalls are not uncommon in the current Internet [CB94]. While 
many dislike their presence because they restrict connectivity, they 
are unlikely to disappear in the near future. Both of these IP 
mechanisms can be used to increase the security provided by 
firewalls. 


Firewalls used with IP often need to be able to parse the headers and 
options to determine the transport protocol (e.g., UDP or TCP) in use 
and the port number for that protocol. Firewalls can be used with 
the Authentication Header regardless of whether that firewall is 
party to the appropriate Security Assocation, but a firewall that is 
not party to the applicable Security Association will not normally be 
able to decrypt an encrypted upper-layer protocol to view the 
protocol or port number needed to perform per-packet filtering OR to 
verify that the data (e.g., source, destination, transport protocol, 
port number) being used for access control decisions is correct and 
authentic. Hence, authentication might be performed not only within 
an organisation or campus but also end to end with remote systems 
across the Internet. This use of the Authentication Header with IP 
provides much more assurance that the data being used for access 
control decisions is authentic. 


Organisations with two or more sites that are interconnected using 
commercial IP service might wish to use a selectively encrypting 
firewall. If an encrypting firewall were placed between each site of 
a company and the commercial IP service provider, the firewall could 
provide an encrypted IP tunnel among all the company’s sites. It 
could also encrypt traffic between the company and its suppliers, 
customers, and other affiliates. Traffic with the Network 
Information Center, with public Internet archives, or some other 
organisations might not be encrypted because of the unavailability of 
a standard key management protocol or as a deliberate choice to 
facilitate better communications, improved network performance, and 
increased connectivity. Such a practice could easily protect the 
company’s sensitive traffic from eavesdropping and modification. 


Some organisations (e.g., governments) might wish to use a fully 
encrypting firewall to provide a protected virtual network over 
commercial IP service. The difference between that and a bulk IP 
encryption device is that a fully encrypting firewall would provide 
filtering of the decrypted traffic as well as providing encryption of 
IP packets. 
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5.2 USE WITH IP MULTICAST 


In the past several years, the Multicast Backbone (MBONE) has grown 
rapidly. IETF meetings and other conferences are now regularly 
multicast with real-time audio, video, and whiteboards. Many people 
are now using teleconferencing applications based on IP Multicast in 
the Internet or in private internal networks. Others are using IP 
multicasting to support distributed simulation or other applications. 
Hence it is important that the security mechanisms in IP be suitable 
for use in an environment where multicast is the general case. 


The Security Parameters Indexes (SPIs) used in the IP security 
mechanisms are receiver-oriented, making them well suited for use in 
IP multicast [Atk95a, Atk95b]. Unfortunately, most currently 
published multicast key distribution protocols do not scale well. 
However, there is active research in this area. As an interim step, 
a multicast group could repeatedly use a secure unicast key 
distribution protocol to distribute the key to all members or the 
group could pre-arrange keys using manual key distribution. 


5.3 USE TO PROVIDE QOS PROTECTION 


The recent IAB Security Workshop identified Quality of Service 
protection as an area of significant interest [BCCH]. The two IP 
security mechanisms are intended to provide good support for real- 
time services as well as multicasting. This section describes one 
possible approach to providing such protection. 


The Authentication Header might be used, with appropriate key 
management, to provide authentication of packets. This 
authentication is potentially important in packet classification 
within routers. The IPv6 Flow Identifier might act as a Low-Level 
Identifier (LLID). Used together, packet classification within 
routers becomes straightforward if the router is provided with the 
appropriate keying material. For performance reasons the routers 
might authenticate only every Nth packet rather than every packet, 
but this is still a significant improvement over capabilities in the 
current Internet. Quality of service provisioning is likely to also 
use the Flow ID in conjunction with a resource reservation protocol, 
such as RSVP [ZDESZ93]. Thus, the authenticated packet 
classification can be used to help ensure that each packet receives 
appropriate handling inside routers. 


5.4 USE IN COMPARTMENTED OR MULTI-LEVEL NETWORKS 
A multi-level secure (MLS) network is one where a single network is 


used to communicate data at different sensitivity levels (e.g., 
Unclassified and Secret) [DoD85] [DoD87]. Many governments have 
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significant interest in MLS networking [DIA]. The IP security 
mechanisms have been designed to support MLS networking. MLS 
networking requires the use of strong Mandatory Access Controls 
(MAC), which ordinary users are incapable of controlling or violating 
[BL73]. This section pertains only to the use of these IP security 
mechanisms in MLS environments. 


The Authentication Header can be used to provide strong 
authentication among hosts in a single-level network. The 
Authentication Header can also be used to provide strong assurance 
for both mandatory access control decisions in multi-level networks 
and discretionary access control decisions in all kinds of networks. 
If explicit IP sensitivity labels (e.g., IPSO) [Ken91] are used and 
confidentiality is not considered necessary within the particular 
operational environment, the Authentication Header is used to provide 
authentication for the entire packet, including cryptographic binding 
of the sensitivity level to the IP header and user data. This is a 
significant improvement over labeled IPv4 networks where the label is 
trusted even though it is not trustworthy because there is no 
authentication or cryptographic binding of the label to the IP header 
and user data. IPv6 will normally use implicit sensitivity labels 
that are part of the Security Association but not transmitted with 
each packet instead of using explicit sensitivity labels. All 
explicit IP sensitivity labels MUST be authenticated using either 
ESP, AH, or both. 


The Encapsulating Security Payload can be combined with appropriate 


key policies to provide full multi-level secure networking. In this 
case each key must be used only at a single sensitivity level and 
compartment. For example, Key "A" might be used only for sensitive 


Unclassified packets, while Key "B" is used only for Secret/No- 
compartments traffic, and Key "C" is used only for Secret/No-Foreign 
traffic. The sensitivity level of the protected traffic MUST NOT 
dominate the sensitivity level of the Security Association used with 
that traffic. The sensitivity level of the Security Association MUST 
NOT dominate the sensitivity level of the key that belongs to that 
Security Association. The sensitivity level of the key SHOULD be the 
same as the sensitivity level of the Security Association. The 
Authentication Header can also have different keys for the same 
reasons, with the choice of key depending in part on the sensitivity 
level of the packet. 


Encryption is very useful and desirable even when all of the hosts 
are within a protected environment. The Internet-standard encryption 
algorithm could be used, in conjunction with appropriate key 
management, to provide strong Discretionary Access Controls (DAC) in 
conjunction with either implicit sensitivity labels or explicit 
sensitivity labels (such as IPSO provides for IPv4 [Ken91]). Some 
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environments might consider the Internet-standard encryption 
algorithm sufficiently strong to provide Mandatory Access Controls 
(MAC). Full encryption SHOULD be used for all communications between 
multi-level computers or compartmented mode workstations even when 
the computing environment is considered to be protected. 


6. SECURITY CONSIDERATIONS 


This entire memo discusses the Security Architecture for the Internet 
Protocol. It is not a general security architecture for the 
Internet, but is instead focused on the IP layer. 


Cryptographic transforms for ESP which use a block-chaining algorithm 
and lack a strong integrity mechanism are vulnerable to a cut-and- 
paste attack described by Bellovin and should not be used unless the 
Authentication Header is always present with packets using that ESP 
transform [Bel95]. 


If more than one sender uses shares a Security Association with a 
destination, then the receiving system can only authenticate that the 
packet was sent from one of those systems and cannot authenticate 
which of those systems sent it. Similarly, if the receiving system 
does not check that the Security Association used for a packet is 
valid for the claimed Source Address of the packet, then the 
receiving system cannot authenticate whether the packet’s claimed 
Source Address is valid. For example, if senders "A" and "B" each 
have their own unique Security Association with destination "D" and 
"B" uses its valid Security Association with D but forges a Source 
Address of "A", then "D" will be fooled into believing the packet 
came from "A" unless "D" verifies that the claimed Source Address is 
party to the Security Association that was used. 


Users need to understand that the quality of the security provided by 
the mechanisms provided by these two IP security mechanisms depends 
completely on the strength of the implemented cryptographic 
algorithms, the strength of the key being used, the correct 
implementation of the cryptographic algorithms, the security of the 
key management protocol, and the correct implementation of IP and the 
several security mechanisms in all of the participating systems. The 
security of the implementation is in part related to the security of 
the operating system which embodies the security implementations. 

For example, if the operating system does not keep the private 
cryptologic keys (that is, all symmetric keys and the private 
asymmetric keys) confidential, then traffic using those keys will not 
be secure. If any of these is incorrect or insufficiently secure, 
little or no real security will be provided to the user. Because 
different users on the same system might not trust each other, each 
user or each session should usually be keyed separately. This will 
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also tend to increase the work required to cryptanalyse the traffic 
Since not all traffic will use the same key. 


Certain security properties (e.g., traffic analysis protection) are 
not provided by any of these mechanisms. One possible approach to 
traffic analysis protection is appropriate use of link encryption 
[VK83]. Users must carefully consider which security properties they 
require and take active steps to ensure that their needs are met by 
these or other mechanisms. 


Certain applications (e.g., electronic mail) probably need to have 
application-specific security mechanisms. Application-specific 
security mechanisms are out of the scope of this document. Users 
interested in electronic mail security should consult the RFCs 
describing the Internet’s Privacy-Enhanced Mail system. Users 
concerned about other application-specific mechanisms should consult 
the online RFCs to see if suitable Internet Standard mechanisms 
exist. 
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